Purpose of this PR

Fixes UUM-138143 — InputAction.IsPressed() / in-progress style checks could fire at the wrong effective magnitude for Vector2 / stick bindings when developers set pressPoint on the control or on PressInteraction, instead of honoring those thresholds consistently.

Introduces IActuationPressPoint, implements it on ButtonControl, Vector2Control, and (via Vector2Control) StickControl, and threads pressPoint / pressPointOrDefault through InputAction, InputActionState, and InputControlExtensions so press-style polling matches the documented interaction defaults. Adds ActuationPressPointTests and refreshes RespondingToActions.md.

Release Notes

• UUM-138143 — InputAction.IsPressed() (and related press / in-progress behavior) for actions bound to Vector2Control and StickControl now respects per-control pressPoint and binding PressInteraction.pressPoint, aligning with ButtonControl and fixing incorrect early triggers when rewriting default interaction thresholds.

Functional Testing status

• Automated: new ActuationPressPointTests and updates in CoreTests_Actions / CoreTests_Controls cover press-point actuation paths.
• Manual: repro project IN-136917 / scene Input Bug from the ticket; verify console no longer shows IsPressed before processed magnitude reaches the configured press threshold for vector / stick cases.

Performance Testing Status

I have added performance testing for the hot path methods that Hakan flagged and I don't see any major issues when comparing. There is a slight increase in cost of performance of about 0.1ms for 1000 iterations on the GetActuationPressThreshold() method that was asked to be checked.

No new per-frame allocations identified in scope.

Overall Product Risks

Technical Risk: 2 — Touches InputActionState and widely used press APIs; edge cases around magnitude, deadzones, and interactions need regression confidence.

Halo Effect: 2 — Any title using IsPressed / WasPressedThisFrame on Vector2 / stick actions may see timing changes until bindings are tuned; behavior is intended to match documented pressPoint semantics.

Class diagram

Git range analyzed: origin/develop...HEAD (4 commits).

classDiagram
  direction TB

  class IActuationPressPoint {
    <<interface>>
    +pressPoint
    +pressPointOrDefault
  }

  class ButtonControl {
    +pressPoint
    +pressPointOrDefault
  }

  class Vector2Control {
    +pressPoint
    +pressPointOrDefault
  }

  class StickControl {
  }

  class InputAction {
    +IsPressed()
    +WasPressedThisFrame()
    +WasReleasedThisFrame()
  }

  class InputActionState {
  }

  class InputControlExtensions {
    <<static>>
  }

  IActuationPressPoint <|.. ButtonControl
  IActuationPressPoint <|.. Vector2Control
  Vector2Control <|-- StickControl
  InputAction --> InputActionState : uses
  InputControlExtensions ..> IActuationPressPoint : pressPointOrDefault

Documentation Impact

Changes analyzed: origin/develop...HEAD (4 commits).

User-facing: New public IActuationPressPoint; InputAction press-helper remarks/behavior; ButtonControl, Vector2Control, StickControl docs around pressPoint; RespondingToActions.md updated for polling vs pressPoint.

Documentation updates in this PR

• RespondingToActions.md — Clarifies IsPressed / frame helpers vs interactions and pressPoint; review wording and cross-refs after merge.

Follow-up (optional)

• If QA/docs want a dedicated IActuationPressPoint callout in a control reference page, add a short subsection and link from Responding to Actions.

Jira (fetched via MCP): Bug, In Progress, TBD priority, assignee Darren Kelly, label Input-Actions. Ticket summary: InputAction.IsPressed() and IsInProgress() triggers on wrong values when rewriting the default values of Vector2 interactions.